Ethernet was originally devised as a local area network (LAN) communications protocol which operates in a connection-less “packet” or “frame” based communications mode. Ethernet-derived protocols having connection-oriented characteristics have been recently developed. Connection-oriented Ethernet protocols send Ethernet traffic frames over predetermined paths and are suitable for longer distance communication as well as short distance communication. As historically Ethernet networks were relatively localised in geographic extent, in order to send traffic over longer distances, a number of different network domains may be encountered.
In order to send traffic along a path which utilises the communications links of another network domain, a carrier service over that network is used. This requires a suitable point of interconnection between the networks and the carrier and client need to agree the service characteristics for sending client traffic over the carrier network domain.
The relatively large size of the Ethernet frame header compared to rival technologies means that bandwidth is used less efficiently when Ethernet carrier services are provided compared to Multi-Protocol Label Switching (MPLS) for short length client payloads. Short length payloads include, for example, the payloads typically associated with voice communications packets, for example, Voice over Internet Protocol (VoIP). As the size of the Ethernet header is larger than such small payloads they are generally, using current methods, not efficiently carried by Ethernet as a result. The problem of bandwidth inefficiency is increased when the client traffic comprises Ethernet frames which each carry a small payload and which then need to utilise one or more Ethernet carrier networks. As each carrier Ethernet network will require its own Ethernet header to be appended, this increases the amount of additional header information to be sent over the network compared to the original payload.
Header compression schemes in one form or another are already known in the art. However, these operate on timescales which are not suitable for adaptation to Ethernet traffic due to the very high speed communications links that Ethernet can utilize, now that Terabit communication speeds are available. For example, relatively slow speed header compression schemes are known in the art for TCP header compression (for example, as described in the Internet Engineering Task Force (IETF) Request For Comments (RFC) 1144 entitled “Compressing TCP/IP Headers for Low-Speed Serial Links”) and for Real Time Protocol (RTP) header compression.
These schemes compress the traffic headers at the transport layer and above, i.e., at layers in the Open Systems Interconnection (OSI) communications stack above the Ethernet link level (layer 2) of the communications protocol stack. For example, the TCP header compression scheme described in RFC 1144 is used to compress packet IP and TCP headers. RTP header compression is also known to compress a combination of IP, UDP, and RTP headers on a link-by-link basis and is described IETF RFC 2508. Moreover, the TCP and RTP header compression at layer 3 and higher layers in the OSI hierarchy is performed by routers before sending packets to layer 2 switches, which means that header compression must be performed on a link-by-link basis. This increases the delay caused by the compression scheme as each time the compressed traffic is received by another layer 3 node, it must be decompressed unless that node is able to determine all necessary routing information. As a result, to perform such a scheme across multiple routers, the routers would need to have the full layer-3 header information to route the packets, i.e., all nodes along the path of the compressed headers would need to be able to support the compression scheme implemented. Moreover, known TCP and RTP compression schemes are based on shared context information between the compressor and the decompressor and other information such as first-order difference and delta encodings for some fields.
Header compression techniques for MPLS are also known in the art and are described in the Request For Comments documents RFCs 4247 and 4901 circulated by the Internet Engineering Task Force. However known MPLS compression schemes utilise layer 3 or higher compression techniques which actually compress the RTP/UDP/IP headers which are then carried using MPLS traffic units and the MPLS headers retain their standard structure. In other words, in MPLS the traffic units contain traffic which has already been compressed at layer 3 or above, the actual MPLS headers themselves are not compressed.
Open Systems Interconnection Layer 2 communications protocols (Data-Link protocols) such as Ethernet and MPLS operate by forwarding traffic from one node to the next node. Each node thus performs a forwarding operation on a received data protocol (or equivalently traffic) unit which requires address information to be extracted from the header of the data-link layer traffic unit in order to determine the next node the received traffic unit should be forwarded to. Known compression schemes operating at the data-link layer accordingly require the compressed state of a communications traffic unit to be identifiable by all nodes in the carrier network. However, making the compression key detectable within the carrier network imposes an inherent security risk as this provides a potential means of identifying the traffic flow within the carrier network. This makes the traffic flow more vulnerable to detection and/or interception and also enables information such as the path taken by the traffic containing a detectable compression key to be tracked within the carrier network, for example, by hackers etc.